home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Mission 3
/
Mission 3.zip
/
Mission 3.iso
/
demovers
/
hddriv76
/
xhdi
/
xhdi_125.zoo
/
xhdispec.txt
< prev
Wrap
Text File
|
1994-10-09
|
26KB
|
609 lines
@(#)XHDI/xhdispec.txt
@(#)Julian F. Reschke, 9. Oktober 1994
Spezifikation des `XHDI'-Cookies, 9. Oktober 1994
-------------------------------------------------
Cookie-Kennung: "XHDI". Der Parameter zeigt auf die Adresse einer
Routine, die massenspeicherbezogene Funktionen zur Verfügung stellt. Zur
Absicherung steht vor der Routine die Long-Konstante $27011992.
Der Wert des Cookies kann sich im laufenden Betrieb ändern (wg.
Zweitinstallation). Daher ggfs. (z. B. in Accessories) den Cookie
jedesmal NEU abfragen!
ALLE FUNKTIONEN MUESSEN IM SUPERVISOR-MODUS AUFGERUFEN WERDEN. Das
Verhalten für Aufrufe im User-Modus ist undefiniert. Bis auf D0 werden
keine Prozessorregister verändert. Undefinierte Opcodes führen zur
Fehlermeldung EINVFN.
Einige der Funktionsaufrufe -- insbesondere `XHReadWrite()' -- können
zum Aufruf von BIOS- oder XBIOS-Routinen im Betriebssystem und damit zur
Aktivierung des `Critical Error Handler' führen. Im Zweifel muß der
`CEH' also vom Aufrufer abgeschaltet werden.
Für alle Funktionen seien folgende Return-Werte definiert:
TOS-Fehlernummern:
0: OK (OK)
-1: unspezifizierter Fehler (ERROR)
-2: Gerät nicht bereit (EDRVNR)
-15: ungültige Device/Targetnummer (EUNDEV)
-32: falsche Funktionsnummer (EINVFN)
-36: Gerät ist zur Zeit 'reserved' (EACCDN)
-46: BIOS-Device wird vom Treiber nicht bedient (EDRIVE)
SCSI-Fehlernummern (Bereich von -200..-455)
(-200 - N): SCSI-Errorcode N (der `Additional Sense Code' aus Byte 12 des
`Extended Sense Format', siehe Abschnitt 7.2.14 in `draft
proposed American National Standard for information systems -
SMALL COMPUTER SYSTEM INTERFACE - 2 (SCSI-2) March 9, 1990').
IDE-Fehlernummern (Bereich von -456..-711)
(-456 - N): IDE-Errorcode N (Wert des IDE-Fehlerregisters).
Hinweis: SCSI-Fehlercodes können logischerweise nur bei ACSI-/SCSI-
Geräten auftreten. Für Platten am IDE-Interface des `ST-Book' oder
`Falcon030' (oder Maschinen, bei denen ein derartiges Interface
nachgerüstet worden ist), kann auch optional folgende Zuordnung benutzt
werden:
Bit im IDE-
Fehlerregister Bedeutung SCSI-Fehler XHDI-Fehler
1 Track 0 not found $06 -206
0 DAM not found $13 -219
4 ID-Field not found $12 -218
7 Bad block mark $10 -216
6 Uncorrectable error $11 -217
2 Command aborted $20 -232
5 Media Change $28 -240
3 Media Change requested $5A -290
(es empfiehlt sich, die einzelnen Bits in der angegebenen Reihenfolge
zu testen).
Bei andersartigen Geräten, wie zum Beispiel Diskettenlaufwerken an der
Floppy-Controller-Schnittstelle, können auch andere, hier noch nicht
spezifizierte Error-Codes zurückgeliefert werden.
Für die Parameterübergabe gilt die GEMDOS-Übergabe-Konvention. Alle
Parameter werden auf dem Stack abgelegt (zuletzt, also an der niedrigsten
Adresse, der Opcode als 16-Bit-Wert). Das 32 Bit große Ergebnis wird in D0
zurückgeliefert.
Immer dann, wenn dokumentiert ist, daß der Aufrufer Nullzeiger übergeben
darf, bedeutet die Übergabe eines Nullzeigers, daß der Aufrufer sich für
den zurückzuliefernden Wert nicht interessiert. Treibersoftware muß also
solche Zeiger vor einer Dereferenzierung immer überprüfen.
Folgende Datentypen seien vereinbart:
UWORD: 16-Bit, unsigned
LONG: 32-Bit, signed
ULONG: 32-Bit, unsigned
char *: 32-Bit, Zeiger auf eine nullterminierte Zeichenkette
Termini:
major: Major Device Number
0..7: Platten am ACSI-Bus mit Atari-kompatiblen Befehlssatz
8..15: Platten am SCSI-Bus
16..17: Platten an der IDE-Schnittstelle
18..63: Erweiterungen lt. PUN_INFO-Struktur (Feld: pun[])
64: Gerät am Floppycontroller
65..255: weitere eigene Erweiterungen jenseits dem, was AHDI
abdeckt
minor: Minor Device Number (für 'major' 0..15: LUN des ACSI- oder
SCSI-Geräts), maximal 255.
key: Entweder ein 16-Bit-Schlüssel, ermittelt von `XHReserve()', oder 0,
wenn das Gerät nicht reserviert wurde oder der Schlüssel nicht
bekannt ist.
Die einzelnen Funktionen:
-----------------------------------------------------------------------
Opcode 0: UWORD XHGetVersion (void);
Liefert die Protokollversion zurück. Formatbeispiel: $0119 ist Version
1.19 (identisch mit GEMDOS-Sversion(), nur sind die beiden Bytes NICHT
verdreht). Diese Version der XHDI-Spezifikation hat die Versionsnummer
$0125.
-----------------------------------------------------------------------
Opcode 1: LONG XHInqTarget (UWORD major, UWORD minor, ULONG *blocksize,
ULONG *device_flags, char *product_name);
Liefert Informationen über das durch `major' und `minor' spezifizierte
Gerät (in `device_flags': ein Attributvektor, in `product_name':
optional die Produktbezeichnung des Geräts). Mit `XHReserve ()'
vorgenommene Reservierungen werden dabei berücksichtigt.
block_size: Blockgröße auf dem Gerät (für `XHReadWrite()' sehr wichtig).
Normalerweise 512.
device_flags: (Bit gesetzt -> Fähigkeit verfügbar):
Bit 0: Gerät kann gestoppt werden (XH_TARGET_STOPPABLE)
Bit 1: Gerät hat wechselbare Medien (XH_TARGET_REMOVABLE)
Bit 2: Auswurf des Geräts kann verriegelt werden
(XH_TARGET_LOCKABLE)
Bit 3: Medium kann per Kommando ausgeworfen werden
(XH_TARGET_EJECTABLE)
Bit 29: Auswurf des Geräts ist vom Treiber blockiert worden
(XH_TARGET_LOCKED, ab XHDI 1.25).
Bit 30: Gerät ist vom Treiber gestoppt worden (XH_TARGET_STOPPED,
ab XHDI 1.25).
Bit 31: Gerät ist zur Zeit blockiert (XH_TARGET_RESERVED).
Alle weiteren Bits sind reserviert und sollten vom Treiber
auf Null gesetzt werden.
product_name: Produktbezeichnung des Geräts (max. 33 Zeichen inkl.
Leerzeichen). Falls die Information nicht verfügbar ist, wird
eine Zeichenkette der Länge Null zurückgeliefert.
Anmerkung: für `blocksize', `device_flags' und `product_name' dürfen
auch Nullzeiger übergeben werden.
Anmerkung: für IDE-Geräte wird bei `product_name' gegebenenfalls auf 32
Zeichen gekürzt. Siehe auch die neue Funktion `XHInqTarget2'.
-----------------------------------------------------------------------
Opcode 2: LONG XHReserve (UWORD major, UWORD minor, UWORD do_reserve,
UWORD key);
Reserviert ein Gerät bzw. gibt es wieder frei. Auf reservierte Geräte
kann nur bei Angabe des korrekten Schlüssels per `XHLock()', `XHStop()'
oder `XHEject()' zugegriffen werden.
Sinn: man möchte nicht, daß man eine Wechselplatte per CPX-Modul
entriegeln kann, nachdem sie gerade von einer virtuellen
Speicherverwaltung verriegelt worden ist. Dies sollte nur die
Speicherverwaltung selbst machen können.
Beim Reservieren des Geräts wird im Erfolgsfall ein 16-Bit-Schlüssel
zurückgeliefert. Dieser Schlüssel muß bei allen weiteren Zugriffen auf
das Gerät angegeben sowie beim Wieder-Freigeben angegeben werden.
do_reserve: (1) Reservieren oder (0) wieder freigeben.
key: (nur beim Freigeben benutzt).
-----------------------------------------------------------------------
Opcode 3: LONG XHLock (UWORD major, UWORD minor, UWORD do_lock,
UWORD key);
Verriegelt bzw. entriegelt den Auswurfknopf eines Geräts. Der Treiber
hat sich darum zu kümmern, ob dieser Befehl an das Gerät weitergeleitet
wird oder nicht (falls das Medium nicht verriegelbar ist).
Welchen Code man im Fehlerfall zurückerhält, ist undefiniert. Mehr
Informationen werden allerdings auch nicht benötigt, da man ja mit
`XHInqTarget()' vorher gezielt auf diese Fähigkeit abtesten kann.
do_lock: (1) Verriegeln oder (0) Entriegeln.
key: Falls Gerät reserviert, sonst Null übergeben.
-----------------------------------------------------------------------
Opcode 4: LONG XHStop (UWORD major, UWORD minor, UWORD do_stop,
UWORD key);
Gerät wird gestoppt (geparkt) bzw. gestartet (entparkt).
Welchen Code man im Fehlerfall zurückerhält, ist undefiniert. Mehr
Informationen werden allerdings auch nicht benötigt, da man ja mit
`XHInqTarget()' vorher gezielt auf diese Fähigkeit abtesten kann.
do_stop: (1) Stoppen oder (0) Starten.
key: Falls Gerät reserviert, sonst Null übergeben.
Anmerkung: Bei etwaigen Zugriffen auf das gestoppte Gerät sollte der
Treiber selbst für das Wiederhochfahren sorgen.
-----------------------------------------------------------------------
Opcode 5: LONG XHEject (UWORD major, UWORD minor, UWORD do_eject,
UWORD key);
Medium wird ausgeworfen oder eingezogen.
Welchen Code man im Fehlerfall zurückerhält, ist undefiniert. Mehr
Informationen werden allerdings auch nicht benötigt, da man ja mit
`XHInqTarget()' vorher gezielt auf diese Fähigkeit abtesten kann.
do_eject: Medium auswerfen (1) oder einziehen (0).
key: Falls Gerät reserviert, sonst Null übergeben.
-----------------------------------------------------------------------
Opcode 6: ULONG XHDrvMap (void);
Liefert einen Bitvektor mit den über das XHDI-Protokoll unterstützten
BIOS-Gerätenummern (wie etwa bei `Drvmap()').
-----------------------------------------------------------------------
Opcode 7: LONG XHInqDev (UWORD bios_device, UWORD *major, UWORD *minor,
ULONG *start_sector, BPB *bpb);
Liefert Major Device Number, Minor Device Number, Startsektor und BPB
eines BIOS-Geräts (im Gegensatz zu `Getbpb()' wird dadurch der Media-
Change-Status des Geräts NICHT zurückgesetzt).
Anmerkung: es wird ein Zeiger auf eine vom Aufrufer bereitgestellte BPB-
Struktur übergeben, die vom XHDI-Treiber gefüllt wird.
Return-Wert: OK, EDRVNR (Gerät kann zur Zeit nicht angesprochen werden,
zum Beispiel Medium nicht eingelegt), EDRIVE (falsche Gerätenummer) oder
eine andere Fehlernummer. Bei EDRVNR darf man sich darauf verlassen, daß
`major' und `minor' korrekt zurückgeliefert werden.
Ein `start_sector' mit Wert $FFFFFFFF soll auf eine Partition hinweisen,
die zur Zeit vom Treiber nicht bedient wird (zum Beispiel, wenn ein
Wechselmedium mit 'zu wenig' Partitionen eingelegt ist).
Der zurückgelieferte BPB ist ungültig, wenn das Element `recsiz' Null ist.
Hinweis: ein Dateisystem ist durch major- und minor-Gerätenummer sowie
Startsektor (mit der obigen Einschränkung) exakt spezifiziert. Über die
Art des Dateisystems (FAT oder etwas anderes) ist damit nichts ausgesagt!
Anmerkung: für `major', `minor', `start_sector' und `bpb' dürfen auch
Nullzeiger übergeben werden.
-----------------------------------------------------------------------
Opcode 8: LONG XHInqDriver (UWORD bios_device, char *name, char *version,
char *company, UWORD *ahdi_version,
UWORD *maxIPL);
Liefert Informationen über den Treiber, der das angegebene Gerät bedient.
name: Zeiger auf Zeichenkette mit Treibernamen (max. 17 Zeichen).
version: Zeiger auf Zeichenkette mit Versionsnummer (max. 7 Zeichen).
company: Zeiger auf Zeichenkette mit Namen des Herstellers (max. 17
Zeichen).
ahdi_version: AHDI-Versionslevel (wie PUN_INFO-Struktur).
maxIPL: Höchster IPL, unter dem der Treiber für das angegebene Gerät
arbeitsfähig ist (Normalwert für Treiber, die ihr Timing per
_hz_200 erledigen: 5).
Anmerkung: für `name', `version', `company', `ahdi_version' und
`maxIPL' dürfen auch Nullzeiger übergeben werden.
-----------------------------------------------------------------------
Opcode 9: LONG XHNewCookie (ULONG newcookie);
- OPTIONALE Funktion, darf also mit EINVFN beantwortet werden -
Installiert einen zusätzlichen XHDI-Handler (Vorteil: der XHDI-Cookie
zeigt nach wie vor auf die gleiche Adresse). Wer diese Funktion
unterstützt muß also folgendes tun:
1. Falls dies der erste Aufruf dieser Art ist: anschließend so vorgehen,
als hätte der XHDI-Cookie bei der Installation bereits auf `newcookie'
gezeigt.
2. Falls nicht: Funktion an 'nächsten' Handler weiterleiten.
Wer eine Mehrfachinstallation vornehmen möchte, sollte so vorgehen:
1. Testen, ob `XHNewCookie()' zum Erfolg führt.
2. Anderenfalls den Cookie `per Hand' versetzen.
------------------------------------------------------------------------
Opcode 10: LONG XHReadWrite (UWORD major, UWORD minor, UWORD rwflag,
ULONG recno, UWORD count, void *buf);
Äquivalent zur BIOS-Funktion `Rwabs()' zum Lesen bzw. Schreiben
physikalischer Blocknummern.
rwflag: Bits 0..2: wie in den AHDI-Release-Notes (3.00, 18. April
1990) beschrieben. Bit 3 (physikalischer Modus) wird
ignoriert. Alle weiteren Bits sind reserviert und auf Null zu
setzen.
recno: Sektornummer
count: Anzahl der Blöcke
buf: Zeiger auf Puffer.
-----------------------------------------------------------------------
Opcode 11: LONG XHInqTarget2 (UWORD major, UWORD minor, ULONG *blocksize,
ULONG *device_flags, char *product_name,
UWORD stringlen);
- AB XHDI-Version 1.01 -
Liefert Informationen über das durch `major' und `minor' spezifizierte
Gerät (in `device_flags': ein Attributvektor, in `product_name':
optional die Produktbezeichnung des Geräts). Mit `XHReserve ()'
vorgenommene Reservierungen werden dabei berücksichtigt.
block_size: Blockgröße auf dem Gerät (für `XHReadWrite()' sehr wichtig).
Normalerweise 512.
device_flags: (Bit gesetzt -> Fähigkeit verfügbar):
Bit 0: Gerät kann gestoppt werden (XH_TARGET_STOPPABLE)
Bit 1: Gerät hat wechselbare Medien (XH_TARGET_REMOVABLE)
Bit 2: Auswurf des Geräts kann verriegelt werden
(XH_TARGET_LOCKABLE)
Bit 3: Medium kann per Kommando ausgeworfen werden
(XH_TARGET_EJECTABLE)
Bit 29: Auswurf des Geräts ist vom Treiber blockiert worden
(XH_TARGET_LOCKED, ab XHDI 1.25)
Bit 30: Gerät ist vom Treiber gestoppt worden (XH_TARGET_STOPPED,
ab XHDI 1.25)
Bit 31: Geräte ist zur Zeit blockiert (XH_TARGET_RESERVED)
Alle weiteren Bits sind reserviert und sollten vom Treiber
auf Null gesetzt werden.
product_name: Produktbezeichnung des Geräts (max. `stringlen' Zeichen inkl.
Leerzeichen). Falls die Information nicht verfügbar ist, wird
eine Zeichenkette der Länge Null zurückgeliefert.
stringlen: Länge der für `product_name' übergebenen Zeichenkette.
Anmerkung: für `blocksize', `device_flags' und `product_name' dürfen
auch Nullzeiger übergeben werden. Produktbezeichnungen von IDE-Geräten
können bis zu 40 Zeichen lang sein.
-----------------------------------------------------------------------
Opcode 12: LONG XHInqDev2 (UWORD bios_device, UWORD *major, UWORD *minor,
ULONG *start_sector, BPB *bpb, ULONG *blocks,
char *partid);
- AB XHDI-Version 1.10 -
Liefert Major Device Number, Minor Device Number, Startsektor, BPB (im
Gegensatz zu `Getbpb()' wird dadurch der Media-Change-Status des Geräts
NICHT zurückgesetzt), Länge und Partitionkennung (maximal drei Zeichen
zzgl. terminierender Null) eines BIOS-Geräts.
Anmerkung: es wird ein Zeiger auf eine vom Aufrufer bereitgestelle
BPB-Struktur übergeben, die vom XHDI-Treiber gefüllt wird.
Return-Wert: OK, EDRVNR (Gerät kann zur Zeit nicht angesprochen werden,
zum Beispiel Medium nicht eingelegt), EDRIVE (falsche Gerätenummer) oder
eine andere Fehlernummer. Bei EDRVNR darf man sich darauf verlassen, daß
`major' und `minor' korrekt zurückgeliefert werden.
Ein `start_sector' mit Wert $FFFFFFFF soll auf eine Partition hinweisen,
die zur Zeit vom Treiber nicht bedient wird (zum Beispiel, wenn ein
Wechselmedium mit 'zu wenig' Partitionen eingelegt ist).
Der zurückgelieferte BPB ist ungültig, wenn das Element `recsiz' Null ist.
Wenn die Partitionkennung nicht verfügbar ist (keine Atari-Partitionierung
oder überhaupt keine Partitionierung, beispielsweise bei normal
formatierten Disketten in SCSI-Diskettenlaufwerken), wird als
Partitionkennung eine leere Zeichenkette zurückgegeben.
Bei MSDOS-kompatibel partitionierten Medien wird ab XHDI-Version 1.20 die
ein Byte lange Partitionkennung wie folgt in `partid' abgelegt: partid[0]
= '\0' (Nullbyte), partid[1] = 'D' (für DOS), partid[2] = Kennung.
Hinweis: ein Dateisystem ist durch major- und minor-Gerätenummer sowie
Startsektor (mit der obigen Einschränkung) exakt spezifiziert. Über die
Art des Dateisystems (FAT oder etwas anderes) ist damit nichts ausgesagt!
Anmerkung: für `major', `minor', `start_sector', `bpb', `blocks' und
`partid' dürfen auch Nullzeiger übergeben werden.
-----------------------------------------------------------------------
Opcode 13: LONG XHDriverSpecial (ULONG key1, ULONG key2,
UWORD subopcode, void *data);
- OPTIONALE Funktion, darf also mit EINVFN beantwortet werden -
Dieser Opcode kann für treiberspezifische Erweiterungen benutzt werden.
Auf welche Art und Weise die Daten in `subopcode' und `data' interpretiert
werden, hängt ausschließlich vom betroffenen Treiber ab. `key1' und `key2'
dienen zur Identifikation des anzusprechenden Treibers: `key1' sollte
dabei aus vier druckbaren ASCII-Zeichen bestehen, `key2' aus einem
möglichst willkürlich gewählten Long-Wert (etwa dem Datum der
Definition im BCD-Format).
-----------------------------------------------------------------------
Opcode 14: LONG XHGetCapacity (UWORD major, UWORD minor, ULONG *blocks,
ULONG *blocksize);
- OPTIONALE Funktion, darf also mit EINVFN beantwortet werden -
Diese Funktion liefert in `blocks' die Anzahl der adressierbaren Sektoren
auf dem Medium und in `blocksize' ihre Größe zurück (Vorsicht: je nach
verwendeter Hardware kann die Ausführung dieser Funktion mehrere Sekunden
dauern!).
-----------------------------------------------------------------------
Opcode 15: LONG XHMediumChanged (UWORD major, UWORD minor);
- OPTIONALE Funktion, darf also mit EINVFN beantwortet werden -
Informiert den Treiber darüber, daß das Medium in dem angegebenen Gerät
gewechselt worden ist. Der Treiber sollte daraufhin so vorgehen, als habe
das Gerät selbst einen Medienwechsel gemeldet. OK wird nur dann
zurückgeliefert, wenn die Information richtig verarbeitet wurde (also alle
logischen Laufwerke auf dem Gerät entweder deaktiviert sind oder benutzt
werden können).
-----------------------------------------------------------------------
Opcode 16: LONG XHMiNTInfo (UWORD opcode, void *data);
- OPTIONALE Funktion, darf also mit EINVFN beantwortet werden -
Eine Funktion zum Setzen bzw. zur Abfrage MiNT-spezifischer Informationen.
Folgende Opcodes sind definiert (unbekannte Opcodes werden mit EINVFN
quittiert, OK wird genau dann zurückgeliefert, wenn die verlangte
Funktion korrekt ausgeführt werden konnte):
XH_MI_SETKERINFO (0) [struct kerinfo *data]
Übermittelt in `data' dem Treiber einen Zeiger auf die
MiNT-Kernel-Info-Struktur. Der Treiber kann diese benutzen, um
beispielsweise direkt Kernelfunktionen aufzurufen.
XH_MI_GETKERINFO (1) [struct kerinfo **data]
Erfragt beim Treiber die eventuell schon bekannte Adresse der
MiNT-Kernel-Info-Struktur. Der Zeiger auf die Struktur wird in die in
`data' angegebene Adresse geschrieben (wenn kein Treiber bekannt ist, wird
ein Nullzeiger zurückgeliefert).
-----------------------------------------------------------------------
Opcode 17: LONG XHDOSLimits (UWORD which, ULONG limit);
- OPTIONALE Funktion, darf also mit EINVFN beantwortet werden -
Diese Funktion erfragt beim Treiber die interne Limits des laufenden DOS
bzw. setzt sie. Sie kann zum Beispiel von einem FAT-Dateisystemtreiber
benutzt werden, um den Harddisk-Treiber mitzuteilen, daß sich einige
Limits geändert haben. `which' gibt an, welches Limit erfragt wird,
`limit' gibt den neuen Wert an (Null steht für: nicht ändern). Ergebnis
ist der bisherige Wert für das Limit.
Konstanten für `which':
XH_DL_SECSIZ (0): maximale Sektorgröße auf BIOS-Ebene
XH_DL_MINFAT (1): minimale Anzahl von FATs
XH_DL_MAXFAT (2): maximale Anzahl von FATs
XH_DL_MINSPC (3): Sektoren/Cluster minimal
XH_DL_MAXSPC (4): Sektoren/Cluster maximal
XH_DL_CLUSTS (5): maximale Clusterzahl
XH_DL_MAXSEC (6): maximale Zahl von Sektoren
XH_DL_DRIVES (7): maximale Zahl der vom DOS unterstützen BIOS-Laufwerke
-----------------------------------------------------------------------
Opcode 18: LONG XHLastAccess (UWORD major, UWORD minor, ULONG *ms);
- AB XHDI-Version 1.25 -
Liefert in `ms' zurück, wieviele Millisekunden seit dem letzten
erfolgreichen Lese- oder Schreibzugriff auf das Gerät vergangen sind.
-----------------------------------------------------------------------
Opcode 19: LONG XHReaccess (UWORD major, UWORD minor);
- AB XHDI-Version 1.25 -
Ein Aufruf dieser Funktion veranlaßt den Treiber, das angegebene Gerät auf
einen Mediachange zu überprüfen und gegebenenfalls die
Partitioninformationen entsprechend zu aktualisieren (wie
`XHMediumChanged()', nur daß der Treiber selbst das Gerät befragt, ob ein
Medienwechsel stattgefunden hat).
------------------------------------------------------------------------
Installation mehrerer Programme im XHDI-Cookie
----------------------------------------------
(1) Bei der Installation feststellen, ob der Cookie schon gesetzt ist.
Falls ja, müssen folgende zusätzliche Aufrufkonventionen
berücksichtigt werden:
(2) Bei `XHGetVersion()' zunächst durch den alten Vektor springen und dann
das Minimun der dort erhaltenen und der eigenen Versionsnummer
zurückliefern.
(3) Bei `XHDrvmap()' zunächst den alten Vektor durchspringen und
anschließend die eigenen Drive-Bits hineinodern.
(4) Bei den anderen Funktionen: wenn es das eigene Gerät ist, normal
verfahren. Ansonsten: keinen Fehler melden, sondern durch den alten
Vektor springen.
-------------------------------------------------------------------------
Partitiontyp `RAW'
------------------
XHDI-1.10-kompatible Treiber müssen zusätzlich zu `GEM' und `BGM' den
dritten Partitiontyp `RAW' unterstützen. Für Partitionen dieses Typs
müssen folgende Eigenschaften unterstützt werden:
(1) Die Partitionlänge ist `beliebig' (im Rahmen der 32-Bit-Sektornummern).
(2) Die Partition ist als BIOS-Gerät ansprechbar; Getbpb() liefert einen
Nullzeiger (damit GEMDOS keinen Zugriff versucht, zusätzlich wird
auch der Media-Change-Status für das BIOS-Gerät zurückgesetzt).
(3) Es kann per `Rwabs()' (nicht nur im physikalischen Modus) und
`XHReadWrite()' auf die Partition zugegriffen werden. Dabei wird
die physikalische Blockgröße des Mediums benutzt (siehe
`XHInqTarget()').
(4) `XHInqDev2()' liefert im Gegensatz zu `XHInqDev()' auch die Länge und
den Typ der Partition zurück.
Diese Erweiterungen sollen die Programmierung zuverlässiger
Filesystemtreiber für MiNT (siehe zum Beispiel das Minix-FS) erleichtern.
-------------------------------------------------------------------------
Empfohlene Partitiontypen
-------------------------
BGM GEMDOS-Partition > 16 MB
GEM GEMDOS-Partition < 16 MB
RAW siehe oben
Folgende Typen können optional unterstützt (zum Beispiel anhand einer
konfigurierbaren Liste von Kennungen) werden.
MAC Mac-HFS-Partition, sollte ggfs wie `RAW' behandelt werden
MIX Minix-Partition, sollte ggfs wie `RAW' behandelt werden
QWA QDOS-Partition, sollte ggfs wie `RAW' behandelt werden
SWP Swap-Partition, sollte ggfs wie `RAW' behandelt werden
UNX ASV (Atari Systen V R4), sollte ggfs wie `RAW' behandelt werden
-------------------------------------------------------------------------
Arbitration
-----------
Für Gerätetreiber, die den SCSI-Bus arbitrierend betreiben wollen, muß für
den Rechner eine eigene Gerätekennung vergeben werden. Diese sollte
natürlich einheitlich und nicht auf der Festplatte gespeichert sein. Atari
hat dafür Byte 16 im NVM des Atari TT und Falcon reserviert. Die
Bitbelegung ist:
Bit 0..2: Gerätenummer
Bit 7: Arbitration an (1) oder aus (0)
Die Abfrage der Gerätenummer könnte zum Beispiel wie folgt geschehen:
int
arbitration_id (void)
{
long ret = EINVFN;
unsigned char nvmdata = 0;
OSHEADER *Sys;
long oldstack = Super (0L);
Sys = *_sysbase;
Super ((void *)oldstack);
host_id = -1; /* no arbitration by default */
if (Sys->os_version >= 0x300)
ret = NVMaccess (0, 16, (int) sizeof (nvmdata), &nvmdata);
if (ret == E_OK && (nvmdata & 0x80))
host_id = nvmdata & 7;
return host_id;
}